Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

(graphcache) - Add mergeMode to simplePagination helper #1174

Merged
merged 9 commits into from
Nov 20, 2020

Conversation

hoangvvo
Copy link
Contributor

Resolves #1173

Summary

Peek 2020-11-19 01-32

Set of changes

Adds mergeMode to simplePagination similar to that of relayPagination. Default to inwards, so it will not be a breaking change.

@changeset-bot
Copy link

changeset-bot bot commented Nov 19, 2020

🦋 Changeset detected

Latest commit: 6f1231a

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 1 package
Name Type
@urql/exchange-graphcache Minor

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

Copy link
Collaborator

@JoviDeCroock JoviDeCroock left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good! Thank you for taking the time to PR this, mind adding a changeset by running yarn changeset at the root? This would be a minor for @urql/exchange-graphcache since we're adding a pagination feature! 👍

exchanges/graphcache/src/extras/simplePagination.ts Outdated Show resolved Hide resolved
@hoangvvo hoangvvo force-pushed the feat/simplePagination-mergeMode branch from 46a4b51 to 7b9b54b Compare November 19, 2020 07:54
@hoangvvo
Copy link
Contributor Author

Thanks for such a quick review! I added documentation for mergeMode of Simple Pagination based on that of Relay Pagination. Changeset also added.

@kitten
Copy link
Member

kitten commented Nov 19, 2020

I believe this is misunderstanding what the mergeMode does on Relay pagination.
There it takes care of which order things are merged in, yes, but in relation to how the pagination arguments are used, since before and after cursors can be used for the same list. This then creates ambiguity because both directions can be "outward" from the same point or "inward" towards a shared centre in the list.

I believe mergeMode may not make much sense for simplePagination as we're not dealing with two directions of pagination so inwards/outwards aren't descriptive.

Furthermore I'm unsure the explanation in the RFC is accurate and whether a lot of APIs even use this pattern? Do we have some prior art here?

@hoangvvo
Copy link
Contributor Author

@kitten You are right. I am not familiar with Relay and possibly misusing the term inwards and outwards. Either way, here are the relevant words from relay pagination definition:

Outwards pagination assumes that pages
that come in last should be merged before the first pages, [...] The default inwards pagination assumes that
pagination last pages is part of the same list and come after first pages.

This matches the description of what I am trying to achieve. Perhaps, mergeMode = "before" | "after" or mergeMode = "reverse" | "forward" might be better. It satisfies use-cases of infinite scroll but instead of scrolling down for older items, we scroll up for them. The GIF above demonstrates that.

@kitten
Copy link
Member

kitten commented Nov 19, 2020

@hoangvvo i believe would rename it like that 👍 the reason why the description matches is because for this paragraph it describes rather what happens when we start pagination from in reverse while forward pagination has been used and vice-versa. So the behaviour does match but it's for a subtly different reason 😅

@hoangvvo
Copy link
Contributor Author

hoangvvo commented Nov 19, 2020

@hoangvvo i believe would rename it like that the reason why the description matches is because for this paragraph it describes rather what happens when we start pagination from in reverse while forward pagination has been used and vice-versa. So the behaviour does match but it's for a subtly different reason

I agree that it is still a somewhat uncommon pattern. I can definitely workaround this by simply reverse the returned GraphQL array appropriately.

offset = 0 => 9,8,7
offset = 3 => 6,5,4

The current simplePagination will merge it into [9,8,7,6,5,4] and I would only need to reverse it to achieve the above effect. So it is okay to not putting this into the helper.

Otherwise, how would you rename it? I am steering toward mergeMode = "before" | "after" with the default being after, where pages with higher offset will be put after, and can otherwise be "before" where pages with higher offset will be put before. The doc will also be updated to reflect this instead of using the terms inwards and outwards:

offset = 0 => 7,8,9
offset = 3 => 4,5,6
mergeMode = "before" => [4,5,6,  7,8,9]
mergeMode = "after" => [7,8,9,  4,5,6]
```

@hoangvvo
Copy link
Contributor Author

@kitten I updated the RFC to clarify the intention and approach

@kitten
Copy link
Member

kitten commented Nov 19, 2020

Awesome! Yea, I think 'before' | 'after' is definitely the most intuitive solution 👍

Copy link
Member

@kitten kitten left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There's one more section in the docs that needs updating, but I can totally do that after this PR myself if you'd like ✌️ https://github.com/FormidableLabs/urql/blob/main/docs/api/graphcache.md#simplepagination

Thanks for adding this!

'@urql/exchange-graphcache': minor
---

Add mergeMode = 'before' | 'after' to simplePagination helper to define whether pages are merged before or after when you paginate forwards and backwards
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
Add mergeMode = 'before' | 'after' to simplePagination helper to define whether pages are merged before or after when you paginate forwards and backwards
Add a `mergeMode: 'before' | 'after'` option to the `simplePagination` helper to define whether pages are merged before or after preceding ones when pagination, similar to `relayPagination`'s option

Just suggesting some details here since we can use full markdown in our changelog 😇

Comment on lines 195 to 196
You can also specify `mergeMode`, which defaults to `after` and can otherwise
be set to `before`. This will handle how pages are merged when you paginate
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
You can also specify `mergeMode`, which defaults to `after` and can otherwise
be set to `before`. This will handle how pages are merged when you paginate
We may also add the `mergeMode` option, which defaults to `'after'` and can otherwise
be set to `'before'`. This will handle in which order pages are merged when paginating

We usually use "we" as often as possible when writing (with some exceptions). I realise the Graphcache pages may need some revamping to make sure they're as helpful as can be compared to some others, but let's take that into account here

@hoangvvo
Copy link
Contributor Author

Thanks for the review, I updated the documentation and also added to graphcache.md.

@kitten kitten merged commit 2f8db84 into urql-graphql:main Nov 20, 2020
@github-actions github-actions bot mentioned this pull request Nov 20, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

RFC: Add mergeMode to simplePagination helper
3 participants